Thanks — this is a clean, additive change: default-off, reuses the batch emitter rather than forking it, and the in-process gRPC server tests (method, routing header, auth, resource attrs, NOP header, caller extensions) are a nice pattern. The cross-domain source guard is a good touch.

I ran the package locally at c2f5a8a (go test ./pkg/beholder/ -race: pass, 81.8% coverage; new tests ×10 with -race: no flakes) plus a few lifecycle/outage probes. Two things I'd like addressed, the rest is optional.

1. Domain emitters close their gRPC connection twice → Client.Close() always returns errors (blocking)

ChipIngressBatchEmitterService.stop() calls e.batchClient.Stop() and then e.ownedClient.Close(), but batch.Client.Stop() already closes the chipingress client (pkg/chipingress/batch/client.go, end of Stop). With the flag on, a clean start → Close() returns three extra errors:

rpc error: code = Canceled desc = grpc: the client connection is closing   (×3, one per domain)

It's hidden in the tests because every Close() result is discarded (t.Cleanup(func() { _ = client.Close() }), _ = client.Close() in the drain test).

Suggestion: drop the ownedClient.Close() from stop() (Stop owns the connection once started) but keep closing it on the construction-failure paths in newDomainEmitters / NewGRPCClient, and assert in a test that a start → close with domain emitters returns no domain-related error.

2. During an outage, every dropped event logs at Error (before enabling the flag on a fleet)

queue() logs failed to emit to chip ingress inside the per-message callback for every non-PublishError failure, and failed to queue message for chip ingress for every ErrMessageBufferFull. When one domain's chip ingress (or its LB rule) is unavailable — or the server doesn't have PublishBatchNoAck yet (Unimplemented, no fallback) — each node emits one Error line per telemetry event for that domain. This is pre-existing behaviour moved into queue(), but domain emitters are going to carry node telemetry volume, so the blast radius is new.

Could we rate-limit these (e.g. first failure + periodic summary per error_code), or log per batch and rely on chip_ingress.events_dropped{error_code} for per-event accounting, as the code already does for PublishError? Fine to do as a fast follow if you prefer, as long as it lands before the flag is turned on anywhere.

Tests worth adding

• Outage/failure injection for domain emitters: server down, hung server + Close (callbacks fire exactly once), buffer full, Unimplemented.
• Concurrent EmitEvent + Client.Close() under -race.
• Construction-failure branches (newDomainEmitters is at 76%: NewClient error, batch-service ctor error, both cleanup defers).
• Emit (attribute path) happy path on a domain emitter — only the reject case is covered.

Nits (optional)

• var domains = []Domain{...} is a mutable package var; a func or a fixed-size array avoids accidental mutation.
• append(append([]chipingress.Opt{}, opts...), ...) → slices.Concat(...).
• svc.ownedClient / svc.domain are set after construction; passing them through the constructor keeps it in one place.
• checkDomain is case-sensitive and requires the . separator; worth a line in the DomainEmitter doc.
• Mention in the ChipIngressDomainEmittersEnabled doc that domain emitters are always batch emitters (independent of ChipIngressBatchEmitterEnabled), and the per-node cost: one buffer of ChipIngressBufferSize per domain; a connection only for domains actually used (dialing is lazy).

Questions

1. What does the LB do with an unknown or missing chainlink-domain header (default backend vs reject, which gRPC status)?
2. Is a chip-ingress server version with PublishBatchNoAck already deployed in stage/prod?
3. Will consumers (OTI) need a beholdertest fake for DomainEmitter?

Out of scope here (I'll track separately)

• pkg/chipingress/batch: splitMessagesByRequestSize recomputes proto.Size over the whole candidate batch for every appended message — O(n²), and ~90% of allocations on the send path in a memprofile. Not introduced by this PR, but this PR adds three more emitters on that path.
• Client shutdown order: OTel providers are shut down before the batch/domain emitters drain, so drain-time metrics/spans are lost.

Happy to approve once (1) is fixed and there's an outage test.

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 2.

This comment was automatically generated by workflow using github-action-benchmark.

👍 💯 sgtm!